In the rapid development of computers many advancements have been seen in the areas of processor speed, throughput, communications, and fault tolerance. Initially computer systems were standalone devices in which a processor, memory and peripheral devices all communicated through a single bus. Later, in order to improve performance, several processors were interconnected to memory and peripherals using one or more buses. In addition, separate computer systems were linked together through different communications mechanisms such as, shared memory, serial and parallel ports, local area networks (LAN) and wide area networks (WAN). Further, with the development of the Internet and advancements in its cellular and wireless communications, it is now possible for computers to communicate without the use of wires, such as provided by the public switched telephone network (PSTN), over great distances.
With the advent of local area networks, wide area networks, and the Internet, manufacturers of servers saw the need for the ability to remotely monitor the physical health characteristics of these servers. Such physical health characteristics include, but not limited to, temperature, voltage, fans, power supplies and chassis access. In order to facilitate the ability to monitor different servers from different manufacturers the IPMI specification version 1 and 1.5 was developed. Such an IPMI specification was intended to facilitate the access and monitoring of different servers from different suppliers. Therefore, as illustrated in FIG. 1, a server 30 and console 10 with the appropriate IPMI specification hardware and software installed in both would allow the console 10 to access server 30 over a packet switched Internet protocol (IP) network 20 and determine the status of servers 30 from a remote location. It should be noted that console 10 may be any type of personal computer (PC) or other processor based system.
However, the specific command and format of acquiring chassis status has been implemented differently by different manufacturers. Therefore, even when a server is IPMI compliant hardware it may not be possible for the same component instrumentation software from another manufacturer to be assured of being able to request and receive chassis status. Further, events relating to the chassis status of a server 30 being reported to the IPMI system event log are accessed by the component instrumentation software. Different manufacturers may implement the events in a different way that the component instrumentation software from another manufacturer may not understand.
Therefore, what is required is a system and method whereby regardless of the specific implementation of chassis status within a server it will still be possible for a component instrumentation software that is IPMI compliant to access chassis status. Further, regardless of the different formats of the events for chassis status, events would still be received and understood by the component instrumentation software.